High speed digital systems, whether for computational or communications purposes, rely on the ability to correctly ascertain the logical value of a data signal at specific times. A series of such consecutive logical values will represent either data or control information, and if satisfactory system performance is to be achieved the error rate in ascertaining the logical values may need to be very low, often only one error in 1012 bits, or even less.
The data signal that is of interest in such a system is generally a binary one, in that while it manifests itself as an analog property (e.g., a voltage causing an associated current), it is described as having only two valid states: logical TRUE, and logical FALSE. These are sometimes also called ‘high’ and ‘low,’ respectively, although these terms suggest their analog implementation, which can vary from one instance to the next. In any event, there are abrupt transitions between the logical values, and the minimum period of time that the data signal can represent a particular logical value is called the UI (for Unit Interval). Generally there is provided (or derived) another signal, called a clock signal, whose period is also the UI and whose abrupt transitions in a selected direction serve as the ‘specific times’ (mentioned above) at which the logical value of the data signal is to be ascertained, a process often termed ‘sampling.’
In an ideal world, no transitions in the data signal would occur except at locations along a time axis that were an exact UI apart, or at exact multiples of the unit interval. Likewise, the transitions in the clock signal would always occur at locations along the time axis that describe exactly a series of consecutive unit intervals. It is common for the phase of the clock signal to be adjusted relative to the transitions in the data signal such that the sampling according to the clock signal will occur in the middle of the unit interval of the data signal. That is, while the UI of the data signal is the same as the UI of the clock signal, they don't coincide, but are instead staggered.
By definition, the UI of a high speed digital system is “small” and arranging for edges of signals to occur exactly when they are supposed to is (pardon the pun) no small matter. The ‘rattle’ in the edges of a signal that is supposed to transition only at particular times (here, at the expiration of consecutive unit intervals) is called jitter. In today's high performance digital systems, the presence of jitter in the data signal and in the clock has a significant effect on the system's ability to correctly ascertain the logical value of the data signal. There are other error causing mechanisms, to be sure, but if a high speed digital system is to offer good performance it needs to have low jitter.
In the old days the measurement of jitter could be performed by eye while observing the varying positions of an edge of a signal with an oscilloscope. Jitter was generally jitter, and so long as it was a small enough percentage of the unit interval, the issue was generally left alone. Today, however, modern systems need a more sophisticated approach. Amounts of jitter that are not easily seen in a live trace with the eye may be significant, as is an understanding of what kind of jitter is occurring. That is, to reduce jitter one generally has to locate its source, and it turns out that it is useful and productive to recognize several different types of jitter. It is now common for test equipment intended for use with high performance digital systems to include in their repertoire of operations automated measurements of jitter, and to do so while recognizing several different types of jitter, each of which can be separately characterized. Total jitter is the aggregate amount of observable jitter, and is (or ought to be) the ‘sum’ of all the various types of component jitter that can be recognized.
This is all well and good, but different types of test equipment (BERTs, or Bit Error Rate Testers, EDAs, or Eye Diagram Analyzers, and various types of DSOs, or Digital Sampling Oscilloscopes) each have internal architectures that favor a balance between cost and performance for accomplishing their main task. Adding an effective and accurate jitter measurement technique (and there are several) to such an apparatus must be done in a way that co-exists with whatever architecture that is already there. Sometimes the marriage is pleasing, and at other times it has left something to be desired. Sometimes the technique selected for jitter measurement does not produce results that are always accurate, or, it takes forever (hours, or even days!) to get accurate results having resolution in parts in 1012.
Suppose, for example, that one were to simply apply a brute force approach for a signal whose UI were one nanosecond. It is customary for the measurement to occur within a setting where a selected test sequence of data is sent repeatedly, say one that is repetitions of a test pattern of 127 bits. (Patterns in the data have an effect on jitter, so test patterns that are known or thought to be trouble makers are used to form the test sequence. Since we don't always know for sure ahead of time what those are, a usual way to do that is to use a PRBS—Pseudo Random Binary Sequence—of 2n-1 bits.) So, that's a little over a hundred nanoseconds for the test pattern. To simplify the numbers, let's just call it one hundred. Now, if you are conducting trials of independent events, and want to know how many times out of N-many trials some event condition happens, you are generally obliged to conduct N-many trials. You will not have confidence in the rate information until either the detected events begin to appear with sufficient frequency to be predictable, or, the number of trials conducted indicates that the probability of the event is below a threshold of concern. In the first case it might not be necessary to do all N-many trials if the rate of events is high. In our area of interest that would correspond to discovering very early on that “Yup, that jitter is REALLY bad . . . ” But if it is low, as desired, then you might find your self waiting until all 1012 instances of the test pattern have occurred. Neglecting overhead, that's 1012 periods of one hundred nanoseconds, or 105 seconds. The reader is reminded that there are only 3,600 seconds in an hour, 86,400 seconds per day, for about 1.15 days to complete the measurement. Clearly, the brute force approach is not suitable for characterizing expected low rates of jitter.
Various strategies have been developed to cope with this situation. These often revolve around assuming that some of the jitter is random in nature, with the rest arising from various other mechanisms. The idea is that, if the nature of a component source of jitter is known, then it can be represented by a model. The significance of this is that, while the model needs coefficients to produce greater or lesser amounts of jitter, the shape of the probability distribution of that jitter component is specific to the model, so that the particular coefficients for a specific instance can be found by curve fitting techniques operating on suitable samples. The plan is to sample for a reasonable amount of time, do a curve fit to instantiate the model, and then let the model predict with some confidence what we would get if we let the measurement run to conclusion using brute force techniques.
Now a new set of difficulties arises. The measured data will contain the effects of all the different types of jitter. It is not possible to readily directly measure each of the component types of jitter, since we can't observe them in isolation. Not only must indirect methods be developed, but there is more than one way to decompose into components the combined jitter that is measured.
We are particularly interested here in a jitter measurement technique that is useable in a real time DSO (or comparable environment), and that produces credible and valid results in seconds instead of hours. While there are various techniques that are known for accomplishing that, each suffers from some disadvantage. For example, one technique operates quickly, but does not preserve observed frequency information for period jitter, which is useful diagnostic information for an attempt to eliminate such jitter. As a second example, another technique does not readily allow the combining of multiple measurements to obtain a more accurate answer. Still another disadvantage of some conventional techniques is that they do not accommodate an arbitrarily long test sequence. There is a need for a jitter measurement technique using a real time DSO that operates quickly, preserves useful ancillary information, whose resolution scales with longer measurement times, and that tolerates test sequences of arbitrary length. What to do?